home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / UNSPLIT / text0096.txt < prev    next >
Encoding:
Text File  |  1997-02-06  |  2.8 KB  |  62 lines
  1.  
  2. > IIRC Motorola claims 6 operations per instruction cycle for the 56k, but
  3. > then one instruction cycle is two clock cycles, which may well be the case
  4. > with the TI chip as well.
  5.  
  6. The 56000/1 Reference claims 7 operations/instruction cycle. This does of course
  7. depend on how you define an 'operation'. The 56k's main advantage is multiple
  8. parallel data busses.
  9.  
  10. Most of the TI DSP / GPU processors I have worked with take either 4 or 2
  11. clock cycles per instruction cycle - some are even binary compatible with
  12. the DSP56000. It is of course possible these particular chips are very recent
  13. and only require a single oscillator cycle per instruction (or less), but more
  14. details are needed before we can know the answer. 
  15.  
  16. The most common TI DSP is almost identical to the 56k, but each instruction takes
  17. exactly twice as long to execute. The clock rate is around 50-80Mhz. I can't 
  18. remember the name, but it's something like TMS34010/20.
  19.  
  20. The reciprocal/sqrt functions sound encouraging - and since it's a DSP specific
  21. implementation, they are likely to be average/low latency (high for a DSP of
  22. course!) as these instructions (along with mult/div) normally form the core
  23. purpose of such chips. Such instructions usually absorb a very large percentage
  24. of the available silicon in order to produce an effective hardware solution to
  25. arithmetic and vector calculations. I doubt they will be anywhere near as slow
  26. as software implementations.
  27.  
  28. An example is the cascading bitwise root algorithm for the DSP56k, which can
  29. produce a 24-bit square root in around 24*5 cycles - but a hardware implementation
  30. can parallelise the 5 intermediate stages and reduce this to 24 cycles. Dual
  31. execution units can reduce this further to 12 cycles. I imagine these new opcodes
  32. will be implemented with the same attitude.
  33.  
  34. > Yes, isn't TI the producer of that monster with multiple DSPs and multiple
  35. > RISC processors on one chip, capable of executing something like 10^9
  36. > instructions/second?
  37.  
  38. 1000 MIPS? I'm sure that will encourage efficient program design. :)
  39.  
  40. > But how would they connect it?
  41. > It seems that for many things the bus is the bottleneck even with the
  42. > relatively slow DSP we have now.
  43.  
  44. I'd be happy just to see Falcon developers making use of the DSP we already
  45. have before adding even more. Relatively slow it may be, but it's still much
  46. more capable than Falcon users seem to think.
  47.  
  48. It would be great to see people shake this concept of a fancy soundchip and
  49. start using it to remove bottlenecks. There are a few out there using it for
  50. a variety of purposes, but most still treat it like an add-on sample player.
  51.  
  52. > with a Afterburner (the best thing would be to stick this card directly on the
  53. > Afterburner giving a fast 32-bit bus!!) it will go into warp speed.
  54.  
  55. > Is there such a bus to use on the AB040?
  56.  
  57. Yes, there appears to be a 32-bit local data bus in addition to the standard
  58. expansion slot.
  59.  
  60. Doug.
  61.  
  62.